In order to improve test efficiency, different types of automated test tools, such as the Rational Functional Tester of IBM, have been developed.
In a typical automated testing scenario, a tester performs a series of actions on an application under test in recording mode of an automated test tool meanwhile, the test toot will generate a test script based on the actions performed. Actions, identification properties (values of the identification properties) of the target objects, and expected property values of some target objects are recorded in the test script. Such a generated test script can then be played back automatically by a test tool in a test locale.
FIG. 1 shows the flow chart of an illustrative process of playing back a test script in a test locale.
First, in Step S101, the automated test tool checks whether there is a next test instruction in the test script. It proceeds to Step S105 and return a message showing that test is ended if there is no more test instructions. Otherwise, it proceeds to Step S110 to fetch the next test instruction.
In Step S115, the automated test tool tries to search a target object based on identification property value of the object recorded in test script. In Step S120, it is determined whether the target object is found. It proceeds to Step S130 to return a message indicating that the test is unsuccessful, if the target object is not found. Otherwise, it proceeds to Step S125 to determine the type of the instruction.
The process proceeds to Step S135 if the instruction is determined to be an action instruction. In Step S135, the action recorded in test script is performed against the target object. And then it returns to Step S101 to continue the process.
The process proceeds to Step S155 if the instruction determined in Step 125 is a comparison instruction, where the property value of the target object is compared to an expected property value. In Step S160 it is determined whether the comparison result is that the two values are identical. When the comparison result is “not identical”, the process proceeds to Step S165 to record an error in the test log. Otherwise, it returns to Step S101 to continue the process.
FIG. 2 shows the target object search process performed in Step S115 in FIG. 1.
In FIG. 2, firstly, the automated test tool determines whether there is a next candidate object in Step S201. If it is determined that there is no more candidate object, the automated test tool returns a message indicating that the target object search is unsuccessful in Step S205. If there is a next candidate object, the automated test tool takes the candidate object as the current object, and fetches the identification property value of the current object in Step S210. In Step S215, it compares the identification property value of the current object to the identification property value of a target object recorded in the test script to determine whether the two values are identical. When the two values are identical, it proceeds to Step S220 to return a message indicating that the target object search is successful. Otherwise, it returns to Step S201 to continue the target object search process.
FIG. 3 shows the property value comparison process performed in Step S155 in FIG. 1.
In Step S301, the process compares the property value of the searched target object to the expected property value of the corresponding object recorded in the test script. When the two values are identical, it proceeds to Step S305 to return a message indicating that the comparison result is “identical”. Otherwise, when the two values are not identical, it proceeds to Step S310 to return a message indicating the comparison result is “not identical”.
Globalized software products need to be tested in different locales to verify their functions in different language locates. A globalized software product usually has different appearances in different language locales, such as in China and in US. For example, English interfaces are used in US while Chinese interfaces are used in China. It means that the property values for the same object are different in different language locales.
Traditional automated test tools compare property values of objects literally. For example, in Step S215 of FIG. 2 and Step S301 of FIG. 3, the property values are compared with each other literally.
There is a problem with traditional automated test tools. That is, the test script generated in one language locale cannot be played back correctly in another language locale. Taking the target object “Press button” as an example, the property value of it in the test script generated in English locale is “OK” in English, while the property value of it in the test script generated in Chinese circumstance is “” in Chinese. And thus the test script generated in English circumstance will not be able to play back correctly in Chinese locale. In particular, in Step S215 in FIG. 2 and Step S301 in FIG. 3, it will have a result that the target object search is unsuccessful or the comparison result is “not identical.”
Normally, there are two methods to walk around this problem. One is to modify the generated test script to enable playing back of it in other language locales; the other is to generate different test scripts for different language locales. However, these methods cost much time and efforts, and make scripts difficult to maintain.